Methods, systems and data structures for timecoding media samples

ABSTRACT

Timecoding systems, methods and data structures are described which, in some embodiments, permit a true time to be ascertained from media samples whose timecodes contain an amount of drift which can arise from having non-integer frame rates. Inventive methods incorporate the use of an offset parameter that describes a time difference between a timecode and a true time associated with a media sample. The inventive approaches can be incorporated with and used compatibly in connection with current timecoding paradigms such as SMPTE timecode and the like. Further embodiments permit timecoding to take place at the field level of a frame. This can permit true-time calculations to be done to ascertain the true time associated with individual fields of a frame. In addition, other embodiments provide novel counting compensation methods that are directed to reducing the drift that can be associated with media samples that are sampled at non-integer frame rates.

RELATED APPLICATION

[0001] This application stems from and claims priority to U.S.Provisional application Ser. No. 60/225,498, filed on Aug. 15, 2000, thedisclosure of which is incorporated by reference herein.

TECHNICAL FIELD

[0002] This invention relates to methods, systems, and data structuresfor timecoding media samples.

BACKGROUND

[0003] The concept of recording and using timing information isfundamental to the needs of multimedia applications. Pictures, video,text, graphics, and sound need to be recorded with some understanding ofthe time associated with each sample of the media stream. This is usefulin order to synchronize different multimedia streams with each other,for carrying information to preserve the original timing of the mediawhen playing a media stream for a user, for identifying specificlocations within a media stream, and also for recording the timeassociated with the media samples for purposes of creating a scientificor historical record. For example, if audio and video are recordedtogether but handled as separate streams of media data, then timinginformation is necessary for coordinating the synchronization of thesetwo (or more) streams.

[0004] Typically, a media stream (such as a recorded audio track orrecorded video or film shot) is represented as a sequence of mediasamples, each of which is associated (implicitly or explicitly) withtiming information. A good example of this is video and motion picturefilm recording, which is typically created as a sequence of pictures, orframes, each of which represents the camera view for a particular shortinterval of time (e.g., typically {fraction (1/24)} seconds for eachframe of motion picture film). When this sequence of pictures is playedback at the same number of frames per second (known as the frame rate)as used in the recording process, an illusion of natural movement of theobjects depicted in the scene can be created for the viewer.

[0005] Similarly, sound is often recorded by regularly sampling an audiowaveform to create a sequence of digital samples (for example, using48,000 samples per second) and grouping sets of these samples intoprocessing units called frames (e.g., 64 samples per frame) for furtherprocessing such as digital compression encoding or packet-networktransmission (such as Internet transmission). A receiver of the audiodata will then reassemble the frames of audio that it has received,decode them, and convert the resulting sequence of digital samples backinto sound using electro acoustic technology.

[0006] Proper recording and control of timing information is requiredfor coordinating multiple streams of media samples, such as forsynchronizing video and associated audio content. Even the use of mediawhich does not exhibit a natural progression of samples through timewill often require the use of timing information in a multimedia system.For example, if a stationary picture (such as a photograph, painting, ordocument) is to be displayed along with some audio (such as anexplanatory description of the content or history of the picture), thenthe timing of the display of the stationary picture (an entity whichconsists of only one frame or sample in time) may need to be coordinatedwith the timing of the associated audio track.

[0007] Other examples of the usefulness of such timing informationinclude being able to record the date or time of day at which aphotograph was taken, or being able to specify editing or viewing pointswithin media streams (e.g., five minutes after the camera startedrolling).

[0008] In each of the above cases, a sample or group of samples in timeof a media stream can be identified as a frame, or fundamentalprocessing unit. If a frame consists of more than one sample in time,then a convention can be established in which the timing informationrepresented for a frame corresponds to the time of some reference pointin the frame such as the time of the first, last or middle sample.

[0009] In some cases, a frame can be further subdivided into evensmaller processing units, which can be called fields. One example ofthis is in the use of interlaced-scan video, in which the sampling ofalternating lines in a picture are separated so that half of the linesof each picture are sampled as one field at one instant in time, and theother half of the lines of the picture are then sampled as a secondfield a short time later. For example, lines 1, 3, 5, etc. may besampled as one field of picture, and then lines 0, 2, 4, etc. of thepicture may be sampled as the second field a short time later (forexample {fraction (1/50)}^(th) of a second later). In suchinterlaced-scan video, each frame can be typically separated into twofields.

[0010] Similarly, one could view a grouping of 64 samples of an audiowaveform for purposes of data compression or packet-network transmissionto be a frame, and each group of eight samples within that frame to be afield. In this example, there would be eight fields in each frame, eachcontaining eight samples.

[0011] In some methods of using sampled media streams that are wellknown in the art, frames or fields may consist of overlapping sets ofsamples or transformations of overlapping sets of samples. Two examplesof this behavior are the use of lapped orthogonal transforms [1)Henrique Sarmento Malvar, Signal Processing with Lapped Transforms,Boston, Mass., Artech House, 1992; 2) H. S. Malvar and D. H. Staelin,“The LOT: transform coding without blocking effects,” IEEE Transactionson Acoustics, Speech, and Signal Processing, vol. 37, pp. 553-559, April1989; 3) H. S. Malvar, Method and system for adapting a digitized signalprocessing system for block processing with minimal blocking artifacts,U.S. Pat. No. 4,754,492, June 1988.] and audio redundancy coding [1) J.C. Bolot, H. Crepin, A. Vega-Garcia: “Analysis of Audio Packet Loss inthe Internet”, Proceedings of the 5th International Workshop on Networkand Operating System Support for Digital Audio and Video, pp. 163-174,Durham, April 1995; 2) C. Perkins, I. Kouvelas, O. Hodson, V. Hardman,M. Handley, J. C. Bolot, A. Vega-Garcia, S. Fosse-Parisis: “RTP Pyaloadfor Redundant Audio Data”, Internet Engineering Task Force Request forComments RFC2198, 1997.]. Even in such cases it is still possible toestablish a convention by which a time is associated with a frame orfield of samples.

[0012] In some cases, the sampling pattern will be very regular in time,such as in typical audio processing in which all samples are created atrigidly-stepped times controlled by a precise clock signal. In othercases, however, the time between adjacent samples in a sequence maydiffer from location to location in the sequence.

[0013] One example of such behavior is when sending audio over a packetnetwork with packet losses, which may result in some frames not beingreceived by the decoder while other frames should be played for use withtheir original relative timing. Another example of such behavior is inlow-bit-rate videoconferencing, in which the number of frames sent persecond is often varied depending on the amount of motion in the scene(since small changes take less data to send than large changes, and theoverall channel data rate in bits per second is normally fixed).

[0014] If the underlying sampling structure is such that there isunderstood to be a basic frame or field processing unit sampling rate(although some processing units may be skipped), then it is useful to beable to identify a processing unit as a distinct counting unit in thetime representation. If this is incorporated into the design, theoccurrence of a skipped processing unit may be recognized by a missingvalue of the counting unit (e.g., if the processing unit count proceedsas 1, 2, 3, 4, 6, 7, 8, 9, . . . , then it is apparent that count number5 is missing).

[0015] If the underlying sampling structure is such that the sampling isso irregular that there is no basic processing unit sampling rate, thenwhat is needed is simply a good representation of true time for eachprocessing unit. Normally however, in such a case there should at leastbe a common time clock against which the location of the processing unitcan be referenced.

[0016] In either case (with regular or irregular sampling times), it isuseful for a multimedia system to record and use timing information forthe samples or frames or fields of each processing unit of the mediacontent.

[0017] Different types of media may require different sampling rates.But if timing information is always stored with the same precision, acertain amount of rounding error may be introduced by the method usedfor representing time. It is desirable for the recorded time associatedwith each sample to be represented precisely in the system with littleor no such rounding error. For example, if a media stream operates at{fraction (30,000/1001)} frames per second (the typical frame rate ofNorth American standard NTSC broadcast video—approximately 29.97 framesper second) and the precision of the time values used in the system isto one part in 10⁻⁶ seconds, then although the time values may be veryprecise in human terms, it may appear to processing elements within thesystem that the precisely-regular sample timing (e.g. {fraction(1001/30,000)} seconds per sample) is not precisely regular (e.g. 33,366clock increment counts between samples, followed by 33,367 increments,then 33,367 increments, and then 33,366 increments again). This cancause difficulties in determining how to properly handle the mediasamples in the system.

[0018] Another problem in finding a method to represent time is that therepresentation may “drift” with respect to true time as would bemeasured by a perfectly ideal “wall clock”. For example, if the systemuses a precisely-regular sample timing of {fraction (1001/30,000)}seconds per sample and all samples are represented with incremental timeintervals being 33,367 increments between samples, the overall time usedfor a long sequence of such samples will be somewhat longer than thetrue time interval—a total of about one frame time per day andaccumulating more than five minutes of error after a year of duration.

[0019] Thus, drift is defined as any error in a timecode representationof sampling times that would (if uncorrected) tend to increase inmagnitude as the sequence of samples progresses.

[0020] One example of a method of representing timing information isfound in the SMPTE 12M design [Society of Motion Picture and TelevisionEngineers, Recommended Practice 12M:1999] (hereinafter called “SMPTEtimecode”). SMPTE timecodes are typically used for television video datawith timing specified in the United States by the National TelevisionStandards Committee (NTSC) television transmission format, or in Europe,by the Phase Alternating Line (PAL) television transmission format.

[0021] Background on SMPTE Timecode

[0022] SMPTE timecode is a synchronization signaling method originallydeveloped for use in the television and motion picture industry to dealwith video tape technology. The challenge originally faced withvideotape was that there was no “frame accurate” way to synchronizedevices for video or sound-track editing. A number of methods wereemployed in the early days, but because of the inherent slippage andstretching properties of tape, frame accurate synchronization met withlimited success. The introduction of SMPTE timecode provided this frameaccuracy and incorporated additional functionality. Additional sourceson SMPTE include “The Time Code Handbook” by Cipher Digital Inc. whichprovides a complete treatment of the subject, as well as an appendixcontaining ANSI Standard SMPTE 12M-1986. Additionally, a text entitled“The Sound Reinforcement Handbook” by Gary Davis and Ralph Jones forYamaha contains a section on timecode theory and applications.

[0023] The chief purpose of SMPTE timecode is to synchronize variouspieces of equipment. The timecode signal is formatted to provide asystem wide clock that is referenced by everything else. The signal isusually encoded directly with the video signal or is distributed viastandard audio equipment. Although SMPTE timecode uses many referencesfrom video terminology, it is sometimes also used for audio-onlyapplications.

[0024] In many applications, a timecode source provides the signal whilethe rest of the devices in the system synchronize to it and followalong. The source can be a dedicated timecode generator, or it can be(and often is) a piece of the production equipment that providestimecode in addition to its primary function. An example of this wouldbe a multi-track audio tape deck that is providing timecode on one trackand sound for the production on other tracks. Video tape often makessimilar use of a cue track or one of its audio sound tracks to recordand play back timecode.

[0025] In other applications, namely video, the equipment uses timecodeinternally to synchronize multiple timecode sources into one. An examplewould be a video editor that synchronizes with timecode from a number ofprerecorded scenes. As each scene is combined with the others to makethe final product, their respective timecodes are synchronized with newtimecode being recorded to the final product.

[0026] SMPTE Time Address

[0027] SMPTE timecode provides a unique address for each frame of avideo signal. This address is an eight digit number, based on the 24hour clock and the video frame rate, representing Hours, Minutes,Seconds and Frames in the following format:

HH:MM:SS:FF

[0028] The values of these fields range from 00 to 23 for HH, 00 to 59for MM, 00 to 59 for SS, and 00 to 24 or 29 for FF (where 24 is themaximum for PAL 25 frame per second video and 29 is the maximum for NTSC{fraction (30,000/1001)} frame per second video). By convention, thefirst frame of a day is considered to be marked as 00:00:00:01 and thelast is 00:00:00:00 (one frame past the frame marked 23:59:59:24 for PALand 23:59:59:29 for NTSC). This format represents a nominal clock time,the nominal duration of scene or program material and makes approximatetime calculations easy and direct.

[0029] SMPTE Frame Rate

[0030] The Frame is the smallest unit of measure within SMPTE timecodeand is a direct reference to the individual “picture” of film or video.The rate is the number of times per second that pictures are displayedto provide a rendition of motion. There are two standard frame rates(frames/sec) that typically use SMPTE timecode: 25 frames per second and{fraction (30,000/1001)} frames per second (approximately 29.97 framesper second). The 25 frame per second rate is based on European video,also known as SMPTE EBU (PAL/SECAM color and b&w). The {fraction(30,000/1001)} frame per second rate (sometimes loosely referred to as30 frame per second) is based on U.S. NTSC color video broadcasting.Within the 29.97 frame per second use, there are two methods of usingSMPTE timecode: “Non-Drop” and “Drop Frame”.

[0031] The Frames figure advances one count for every frame of film orvideo, allowing the user to time events down to {fraction (1/25)}th, or{fraction (1001/30,000)}th of a second.

[0032] SMPTE timecode is also sometimes used for a frame rate of exactly30 frames per second. However, the user must take care to distinguishthis use from the slightly slower {fraction (30,000/1001)} frames persecond rate of U.S. NTSC color broadcast video. (The adjustment factorof {fraction (1000/1001)} originates from the method by which televisionsignals were adjusted to provide compatibility between modem color videoand the previous design for broadcast of monochrome video at 30 framesper second.)

[0033] Thus, the SMPTE timecode consists of the recording of an integernumber for each of the following parameters for a video picture: Hours,Minutes, Seconds, and Frames. Each increment of the Frames number isunderstood to represent an increment of time of {fraction (1001/30,000)}seconds in the NTSC system and {fraction (1/25)} seconds in the PALsystem.

[0034] However, since the number of frames per second in the NTSC system({fraction (30,000/1001)}) is not an integer, there is a problem ofdrift between the SMPTE 12M timecode representation of time and true“wall clock” time. This drift can be greatly reduced by a special framecounting method known as SMPTE “drop frame” counting. Without SMPTE dropframe counting, the drift between the SMPTE timecode's values of Hours,Minutes, and Seconds and the value measured by a true “wall clock” willaccumulate more than 86 seconds of error per day. When using SMPTE dropframe counting, the drift accumulation magnitude can be reduced by abouta factor of about 1,000 (although the drift is still not entirelyeliminated and the remaining drift is still more than two frame samplingperiods).

[0035] The SMPTE timecode has been very widely used in the videoproduction industry (for example, it is incorporated into the design ofmany video tape recorders). It is therefore very useful if any generalmedia timecode design is maximally compatible with this SMPTE timecode.If such compatibility can be achieved, this will enable equipmentdesigned for the media timecode to work well with other equipmentdesigned specifically to use the SMPTE timecode.

[0036] Within this document, the following terminology is used. Atimecode comprises the data used for representing the time associatedwith a media sample, frame, or field. It is useful to separate the dataof a timecode into two distinct types: the timebase and the timestamp.The timestamp comprises the information which is used to represent thetiming for a specific processing unit (a sample, frame, or field). Thetimebase comprises the information that establishes the basis of themeasurements units used in the timestamp. In other words, the timebaseis the information necessary to properly interpret the timestamps. Thetimebase for a media stream normally remains the same for the entiresequence of samples, or at least for a very large set of samples.

[0037] For example, we may interpret the SMPTE timecode as having atimebase that consists of:

[0038] Knowledge of (or an indication of) whether the system is NTSC orPAL, and

[0039] Knowledge of (or an indication of) whether or not the system usesSMPTE “drop frame” counting in order to partially compensate for drift.

[0040] Given this, the timestamps then consist of the representations ofthe parameters Hours, Minutes, Seconds, and Frames for each particularvideo frame.

[0041] This invention arose out of concerns associated with providingimproved timing systems, methods and structures associated with variousmedia. The invention also arose out of concerns associated withproviding improved timing systems, methods and structures that arecompatible with timecodes in current use, and, in particular, SMPTEtimecodes.

SUMMARY

[0042] Timecoding systems, methods and data structures are describedwhich, in some embodiments, permit a true time to be ascertained frommedia samples whose timecodes contain an amount of drift which can arisefrom having non-integer frame rates. Inventive methods incorporate theuse of an offset parameter that describes a time difference between atimecode and a true time associated with a media sample. The inventiveapproaches can be incorporated with and used compatibly in connectionwith current timecoding paradigms such as SMPTE and the like. Furtherembodiments permit timecoding to take place at the field level of aframe. This can permit true-time calculations to be done to ascertainthe true time associated with individual fields of a frame.

[0043] In addition, other embodiments provide novel countingcompensation methods that are directed to reducing the drift that can beassociated with media samples that are sampled at non-integer framerates.

BRIEF DESCRIPTION OF THE DRAWINGS

[0044]FIG. 1 illustrates an exemplary timecode counter having secondsand frames parameters.

[0045]FIG. 2 illustrates an exemplary timecode counter having offset,seconds and frames parameters.

[0046]FIG. 3 is a flow diagram that describes steps in a method inaccordance with one embodiment.

[0047]FIG. 4 is a flow diagram that describes steps in a method inaccordance with one embodiment.

[0048]FIG. 5 illustrates the concept of fields, as such pertains tomedia sample frames.

[0049]FIG. 6 illustrates an exemplary timecode counter having fieldcounter, offset, seconds and frames parameters.

[0050]FIG. 7 illustrates the concept of fields, as such pertains tomedia sample frames and in conjunction with 2:3 pulldown.

[0051]FIG. 8 is a flow diagram that describes steps in a method inaccordance with one embodiment.

[0052]FIG. 9 is a flow diagram that describes steps in a method inaccordance with one embodiment.

DETAILED DESCRIPTION

[0053] Overview

[0054] Timing systems, methods and structures for use with various mediaare described. Various embodiments provide a means by which an accuratereference to “true time” can be provided in a timecode associated with amedia sample. Various embodiments described below incorporate an offsetparameter that can be used in conjunction with existing timecodes toascertain the true time associated with a particular sample, frame orfield.

[0055] The description below starts first with an explanation of anexemplary timebase in accordance with one embodiment, and then anexplanation of exemplary timestamp parameters associated with oneinventive embodiment.

[0056] Timebase Parameters For A Timecode Design

[0057] Table 1 shows an exemplary full set of parameters used in onedesign for specifying a timebase for use in a timecode in accordancewith one embodiment.

[0058] Some of these parameters can be specified only in a header, orcan be fixed to specific values for a particular system design.Alternatively, some or all of these parameters can be sent with everytimestamp. (If field-based timecodes are not needed in the system, theBaseFPF parameter can be removed and can have an implied value of 1.)TABLE 1 Timecode Timebase Parameters Parameter Name Parameter Type Size(bits) Range of Values MaxDays int  1 or more >0 BaseUPS int 16 ormore >0 BaseUPF int 16 or more >0 BaseFPF int  2 or more >0 CountCompenum  2 or more ‘00’, ‘01’, ‘10’, ‘11’

[0059] Using these parameters, an important derived parameter is definedas follows:

MaxFPS=ceil(BaseUPS/(BaseFPF•BaseUPF)),

[0060] where ceil (x) is defined as a mathematical function of anargument x, which, for non-negative values of x, is equal to x if x isan integer and is otherwise equal to the smallest integer greater thanx.

[0061] The parameters shown in Table 1 and the MaxFPS parameter aredefined semantically as follows:

[0062] MaxDays: The maximum number of days for which the timecode periodis defined.

[0063] BaseUPS: The number of basic units of time (termed clock ticks)in the timebase per second (e.g., 120,000 ticks per second or 50 ticksper second). This parameter can have a general integer value. Thisparameter can also be defined as a specific fixed integer constantdivided by a general integer value. The integer constant can be aninteger multiple of 30,000. This parameter can also have one or morevalues, at least one of which is an integer multiple of 30,000.

[0064] BaseUPF: The number of basic units of time (termed clock ticks)to be added for each field count increment (e.g., 2,002 ticks per fieldor 1 tick per field). This parameter can have a general integer value.This parameter can also have one of multiple values at least one ofwhich is in integer multiple of 1001.

[0065] BaseFPF: The number of fields defined for each frame (e.g., 2fields per frame in interlaced video, or 1 field per frame inprogressive-scan video). If media samples are not each divided into anequal number of fields, the BaseFPF parameter is 1. This parameter canhave a general integer value.

[0066] CountComp: Indicates the method applied to compensate framecounting increments to reduce or eliminate drifts over time between true“wall clock” time and the timecode timestamps. Such is defined as:

[0067] ‘00’: No counting compensation. Drift, if any, is accumulated inthe Offset parameter of the timecode. The Frames parameter simply countsup from 0 to MaxFPS-1 and then starts again at 0.

[0068] ‘01’: SMPTE “drop frame” counting compensation. As the timestampsfor consecutive frames increment past each one-minute mark, the Framesparameter counting starts at 2 rather than 0, except for minutesnumbered 00, 10, 20, 30, 40, and 50. The Frames parameter always countsup to MaxFPS-1. Any drift remaining after performing this compensationis accumulated in the Offset parameter.

[0069] ‘10’: “Top-drop” counting compensation. In order to eliminatedrift over time, the Frames parameter will sometimes count up from 0 toMaxFPS-1 and will sometimes count up only from 0 to MaxFPS-2 (droppingthe top count). Top-drop counting compensation is probably the mostintuitive method—for example, if the basic frame rate is 7.3 frames persecond, then sometimes there will be seven frames counted in a secondand sometimes eight (so the Frames count will sometimes count from 0 upto 6 and sometimes up to 7).

[0070] ‘11’: “Bottom-drop” counting compensation. In order to eliminatedrift over time, the Frames parameter will sometimes count up from 0 toMaxFPS-1 and sometimes will sometimes count up only from 1 to MaxFPS-1(dropping the bottom count). This counting method is similar to that oftop-dropping, but in this case it is the Frames parameter value of 0that is skipped rather than the highest value of the Frames parameter.

[0071] CountComp shall be equal to ‘00’ if BaseUPS/(BaseFPF•BaseUPF) isan integer (as no drift accumulates in this case). CountComp shall notbe equal to ‘01’ or ‘11’ if BaseUPS/(BaseFPF•BaseUPF) is less than one(since the Frames parameter cannot exceed 0 in this case). Furtherinformation on the use of CountComp is provided below.

[0072] Timestamp Parameters for the Timecode Design

[0073] Table 2 shows an exemplary full set of parameters of a specifictimestamp using the timebase defined by Table 1 above. Some of theseparameters could be specified only in a header, or could be fixed tospecific values for a particular system design. It may also be desirablein some system designs to send some parameters more often than others,depending on the receiver to store or infer values for some of theunsent parameters. (If field-based timecodes are not needed in thesystem, the Fields parameter can be removed and have an implied value of0.) TABLE 2 Timecode Timestamp Parameters Parameter Parameter Size Rangeof Name Type (bits) Values Discont enum 2 ‘00’, ‘01’, ‘10’, ‘11’ Hoursint 5 or more 0 to 24·MaxDays−1 Minutes int 7 or more −59 to 59 Secondsint 7 or more −59 to 59 Frames int 7 or more 0 to MaxFPS−1 Fields int 1or more 0 to BaseFPF−1 Offset int 16 or more any integer value

[0074] Conversion to true (real-number-valued) “wall-clock” time inseconds, using the information in the above tables, can be defined asfollows:

t=60˜(60˜Hours+Minutes)+Seconds+(BaseUPF•(BaseFPF•Frames+Fields)+Offset)/BaseUPS

[0075] This timecode definition can be extended in a straightforwardfashion so that rather than using only Hours and MaxDays to specify itsmaximum range, the timestamp definition would also specify a Dayparameter and Hours would be restricted to a range of 0 to 23. Or thetimecode could even include a DayOfMonth, Month, and Year, and thetimebase could specify (implicitly or explicitly) the range of the Yearparameter. However, this last type of definition becomes more complexbecause it begins to bring into question how to account for leap days,leap seconds, etc.

[0076] A discontinuity is a juncture between two consecutive samples forwhich the difference between the time values represented for each of thetwo samples cannot be interpreted as a correct representation of thetrue time interval between these samples. (This is useful to indicatewhen splicing streams together without altering timecode values.)

[0077] The parameters shown in Table 2 are defined semantically asfollows:

[0078] Discont: Specifies whether there is a discontinuity at theboundary between a specific sample and an adjacent sample. Thisparameter is useful to include for editing purposes, as it allowssplicing of two streams of media samples, each of which has its owntimestamps. Defined by the following:

[0079] ‘00’: No discontinuity indicated (unless indicated on adjacentsample timecodes),

[0080] ‘01’: Discontinuity between this sample and next sample,

[0081] ‘10’: Discontinuity between previous sample and this sample,

[0082] ‘11’: Discontinuities between previous, current, and nextsamples.

[0083] Alternatively, the Discont parameter could be a single bit, alongwith a convention that a value of ‘1’ indicates a discontinuity betweenthe previous sample and the current sample (or a convention that itindicates a discontinuity between the previous sample and the next one).

[0084] Hours: An integer parameter which, when multiplied by 3,600,specifies an amount of time (in seconds) to be added as a component ofthe timestamp.

[0085] Minutes: An integer parameter which, when multiplied by 60,specifies an amount of time (in seconds) to be added as a component ofthe timestamp.

[0086] Seconds: An integer parameter which specifies a number of secondsof time to be added as a component of the timestamp.

[0087] Frames: An integer parameter which, when multiplied by BaseUPFand BaseFPF and divided by BaseUPS, specifies an amount of time (inseconds) to be added as a component of the timestamp. The Framesparameter is incremented for each media sample frame, set to zero if theincremented value exceeds MaxFPS-1, and is adjusted for drift asindicated by the CountComp parameter. The Frames parameter shall notexceed MaxFPS-1.

[0088] Fields: An integer parameter which, when multiplied by BaseUPFand divided by BaseUPS, specifies an amount of time (in seconds) to beadded as a component of the timestamp. The Fields parameter isincremented for each media sample field and is set to zero if theincremented value exceeds MaxFPS-1.

[0089] Offset: An integer parameter which, when divided by BaseUPS,specifies an amount of time (in seconds) to be added as a component ofthe timestamp. The Offset parameter is used to specify the precisedifference between the time represented by the other parameters and thetrue “wall clock” time of the media field sample.

[0090] Frame Rate Counting Compensation

[0091] Whenever a media sample rate in frames per second is not aninteger (i.e., whenever BaseUPS/(BaseFPF•BaseUPF)) is not an integer,there may arise a need to adjust for drift between the Hours, Minutes,and Seconds parameters and the Frames count as the sampling sequenceprogresses. The Offset parameter can be used to account for some amountof drift, but there are two problems with using the Offset parameter forthat purpose:

[0092] If too much drift is allowed to accumulate, the range of valuesthat can be represented by the Offset parameter may be exceeded, and

[0093] If too much drift is allowed to accumulate, the Hours, Minutes,and Seconds parameters begin to lose their normal interpretation as theapproximate placement of the sample in normal “wall-clock” time.

[0094] The CountComp parameter indicates how the counting process iscompensated for drift.

[0095] If we define a variable called Drift that contains the value ofOffset needed to represent the accumulated drift, we can then specifythe counting process as it relates to the CountComp variable. The valueof Offset can be set equal to Drift if no alteration of this basicsampling timing is to be indicated. (However, Offset can be set to somevalue other than Drift if desired in order to indicate a differenttiming of samples—two examples of which are provided below).

[0096] The counting process and drift compensation for each increment ofthe Fields parameter can then be defined by the following C++ processdefinition. If some field sample is skipped (not sent), the Fieldsparameter of the subsequent sample is incremented one additional time toindicate the gap in time from the missing sample. In the following C++code fragment, it is assumed that all parameters are processed usingarbitrarily long integer variables (i.e., a parameter may temporarilytake on a value in excess of its stated range in the tables): ++Fields;  // Increment the Fields parameter if (Fields == BaseFPF) { // MaxFields value exceeded Fields = 0; // Indicate first field of next frame++Frames; // Increment the frame count adj = 0; // Drift adjustment if(CountComp == 0x0) { // No counting compensation if (Frames == MaxFPS) {Frames = 0; for (adj=MaxFPS*BaseFPF*BaseUPF; adj >= BaseUPS;adj−=BaseUPS) if (++Seconds == 60) { // adjust Hours, Minutes, SecondsSeconds = 0; if (++Minutes == 60) { Minutes = 0; if (++Hours == MaxDays)Hours = 0; } } } } else if (CountComp == 0x1) { // SMPTE Drop-FrameCompensation if (Frames == MaxFPS) { adj = MaxFPS*BaseFPF*BaseUPF −BaseUPS; Frames = 0; if (++Seconds == 60) { Seconds = 0; if ((++Minutes% 10) != 0) { Frames = 2; adj −= 2*BaseFPF*BaseUPF; } if (Minutes == 60){ Minutes = 0; if (++Hours == MaxDays) Hours = 0; } } } } else if(CountComp == 0x2) { // Top-Drop Compensation if ((Frames >= MaxFPS−1)&& ((Frames == MaxFPS) || (Frames *BaseFPF*BaseUPF+Drift > BaseUPS))) {for (adj=Frames*BaseFPF*BaseUPF; adj+Drift >= BaseUPS; adj−=BaseUPS) if(++Seconds == 60) { Seconds = 0; if (++Minutes == 60) { Minutes = 0; if(++Hours == MaxDays) Hours = 0; } } Frames = 0; } } else if (CountComp== 0x3) { // Bottom-Drop Compensation if (Frames == MaxFPS) { adj =MaxFPS*BaseFPF*BaseUPF − BaseUPS; if (++Seconds == 60) { Seconds = 0; if(++Minutes == 60) { Minutes = 0; if (++Hours == MaxDays) Hours = 0; } }if (adj+Drift >= BaseFPF*BaseUPF) { adj −= BaseFPF*BaseUPF; Frames = 1;}else Frames = 0; } } Drift += adj; }

[0097] Other similar methods of counting compensation may be defined asmethods based on a calculation of the accumulated drift between the timerepresented in the Hours, Minutes, Seconds, and Frames parameters andthe true “wall clock” time of a frame, and skipping over some framecount or counts when the accumulated drift exceeds some threshold valueof at least BaseFPF•BaseUPF in value.

Example 1

[0098] The following example is given in the context of NTSC(approximately 29.97 frames per second) with SMPTE Non-drop Counting.

[0099] A SMPTE NTSC non-drop timecode can be represented in the timecodedata structure fields of CountComp, Hours, Minutes, Seconds, and Frameswithout substantial alteration. The other parameters of the timecodeshould be specified as:

[0100] MaxDays=1;

[0101] CountComp=‘00’; (no counting compensation)

[0102] BaseUPF=1001;

[0103] BaseUPS=30000 (for frame-based timestamps), or 60000(field-based);

[0104] BaseFPF=1 (for frame-based timestamps), or 2 (field-based);

[0105] Fields=0 (for frame-based timestamps), or 0 or 1 (field-based);

[0106] The Offset parameter should be set to the value of Drift ascomputed by the section entitled “Frame Rate Counting Compensation”.(Initially set to zero, then incremented by 30 (frame-based) or 60(field-based) each time the value of Seconds increments.)

[0107] Note that the SMPTE timecode can then later be extracted directlyfrom the CountComp, Hours, Minutes, Seconds, and Frames parameters, asits parameter values have been preserved without alteration.

[0108] As an example, consider the following:

[0109] The United States system for video was originally designed to be30 frames/sec. But, due to advancements in video technology (i.e. theinvention of color television), this was changed slightly. This framerate was changed by a factor of {fraction (1001/1000)}. So now, thenumber of frames in one second of US standard video is {fraction(30,000/1001)}or ˜29.97 (hence, the 29.97 framers per second numberabove).

[0110] This means that if there are timecodes that are counting or arelabeled hours, minutes, seconds, and frames, then if you just count from0-29 repetitively, after some amount of time has passed by, there willbe a drift between the time that the timecode seems to represent, andthe true time or time lapse between one frame and some other sample thatarrives much later. When there are 30 f/s (frames/sec), there is asignificant drift that accumulates between the true time that you wouldmeasure with an accurate clock and what the timecode is representing interms of hours, minutes, and seconds and frames.

[0111] Consider FIG. 1 which shows an exemplary timecode counter 100with a “seconds” column and a “frames” column. The “seconds” columnrepresents a measure of time in seconds. The “frames” column representsa measure of counted frames. (“Hours” and “Minutes” have been eliminatedfor simplicity in this example). The true time lapse represented by aframe count is {fraction (1001/30,000)} sec/frame. The timecode startsat 0—with the hours, minutes, and seconds being 0. The frame count is 1.As the individual frames pass by (for example in a timecode encoder),they are counted and can be assigned a timestamp. The first frame inthis example would be assigned a timestamp of (s=0, f=1) for (seconds,frame). In the next increment, the seconds are still 0, but the framecount is now 2, i.e. (s=0, f=2). Because there are a non-integer numberof frames in one second, drift will begin to accumulate in thetimestamp.

[0112] As the frames are counted up, the frame counter will count up to29 and then roll over so that s=1 and f=0. Consider that the nominaltime lapse between s=0 and f=0 and s=1, f=0 should ideally be onesecond. This is not, however, the case. What has happened is that therehave been 30 increments of {fraction (1001/30,000)} or {fraction(30,001/30,000)} seconds, which is slightly longer than 1 second. Thus,the actual time interval that has elapsed is slightly longer than whatyou see from the timestamp parameters. Thus, the point where s=1, f=0actually occurs after {fraction (30,030/30,000)} seconds of time haveelapsed. The difference of {fraction (30/30,000)} seconds is the driftfor which the use of an offset can compensate.

[0113] In the presently-described embodiment, it is very desirable tohave an understanding of how much time lapse is indicated by anincrement of the frame counter. There is an understanding of how manyunits per second there are in the counting clock. In the present case,we are counting in units of {fraction (1/30,000)} of a second. Thisvalue is expressed by the UPS (units per second) parameter above.Accordingly, the UPS parameter is set to 30,000. Now, one can determinehow much time lapse is indicated in these units by an increment of theframe counter. This value is expressed by the UPF parameter. In thisexample, the UPF parameter is 1001. That is, there are 1001 units of{fraction (1/30,000)} sec that pass each time the frame counterincrements. So, an increment of the frame counter is associated with{fraction (1001/30,000)} seconds.

[0114] Given these two parameters, the true time lapse can beascertained by Multiplying the frame count by UPF/UPS. That is:

(frame count)×(UPF/UPS)=true time lapse indicated by frame count.

[0115] In the first interval (where s=0), you can calculate the truetime by taking the seconds parameter, and then adding to it (framecount)×(UPF/UPS). That is,

True time=s+(frame count)×(UPF/UPS), where s=0

[0116] When the system rolls over into the next second (i.e. s=1), thiscalculation is no longer valid. This is because you have to account forthe difference in time that has lapsed due the association of anon-integer frame rate with an integer counter. This is where, in thisexample, the use of the offset parameter comes into play.

[0117]FIG. 2 shows an exemplary timecode counter 200 with a “seconds”column, a “frames” column, and an offset column. In the example thatfollows, the particular values that are used for the offset parameterare associated with a specific non-integer frame rate. As frame rateschange, so too can the specific values of the offset parameter. Thus, itis to be appreciated and understood that the described examplesconstitute specific solutions to specific circumstances. Accordingly,the claimed subject matter should not be construed to cover only thosespecific examples, except, if and when specified.

[0118] The offset parameter is also in the same units (units per second)so that you reference to the same clock. The offset parameter isinitially set to 0. When the seconds counter rolls over to its nextvalue (i.e. 1), the offset parameter is incremented by 30. A formula tocalculate true time is now given as:

True time=s+(frame count×UPF+offset)/UPS

[0119] So, calculating the true time when s=1, f (frame count)=0, andoffset=30 gives: 1+(0+{fraction (30/30,000)}) {fraction (30,030/30,000)}seconds. Now, by adding the offset parameter, you are able to use thetraditional counting method (SMPTE timecode), but you are also able tocalculate a precise time associated with the sample.

[0120] The offset is selected as a function of the true frame rate.Recall that the true frame rate is typically some fractional number offrames per second. The inverse of this is the number of seconds/frame.

[0121] As the above example proceeds through the seconds, you will getto a point where s=2, f=0. Here, you increment the offset by another 30so that it becomes 60. Effectively, the offset increases as more andmore time goes by. In each case, though, what the offset is doing istelling you is how to get from the parameters that you have in thetraditional SMPTE timecode to a true time associated with that sample.

[0122] Application of the inventive techniques should not, however, belimited only to cases where there is a fractional frame rate.Specifically, if there is an integer number of frames in a second (e.g.in the European system there are 25 frames/sec.), then the offset canalways just be 0 because there will not be any drift. However, theability to use an offset to indicate a time that may differ from thenominal time represented in the SMPTE timecode also has other uses, suchas, for example, providing the ability to indicate that the sampling ofthe original samples differs from the timing indicated by the nominaltime represented in the SMPTE timecode.

[0123] To a large extent, the problem associated with old styletimecodes, such as SMPTE, is that there is not a clear understanding ofwhere true time is relative to the clock associated with the timecode.Using the principles described above, an offset parameter is providedand can be used to ascertain the true time associated with individualframes, or, as we will see below, portions of frames.

[0124]FIG. 3 is a flow diagram that describes steps in a method inaccordance with one described embodiment. The method can be implementedin any suitable hardware, software, firmware, or combination thereof. Inthe illustrated example, the method is implemented in software.

[0125] Step 300 provides one or more media samples. The media samplescan be any suitable media samples. In addition, the media samples can beprovided in any suitable format. For example, the media samples cancomprise frames or fields, to name just two. Step 302 provides atimecode encoder that is configured to provide timecodes with offsetparameters. As described above, the use of the offset parameter isadvantageous in that it enables old timecodes that do not have anaccurate understanding of true time to be used and, in a sense,retrofitted with a parameter that can be used to ascertain from the oldtimecode data, the true time associated with the sample.

[0126] Step 304 processes the media samples using the timecode encoder.This step can be implemented by providing one or more of the sampleswith timecodes having the offset parameter. Once the samples areprocessed, step 306 provides the media samples to a receiver. This stepcan be implemented in any suitable way and need not, necessarily, beimplemented at the same time the timecodes are provided on the mediasamples. For example, the timecodes might be provided when a particularmovie is initially produced. Step 306 might be implemented when themovie is distributed to various entities that might be interested inreceiving the movie, i.e. editors, vendors, and the like.

[0127] Step 308 receives the media samples having the timecodes with theoffset parameters. This step can be implemented in any suitable manner.For example, this step might be implemented by providing the mediasamples to an editor that is interested in editing the samples. Step 310calculates a time associated with one or more samples using the offsetparameter. The time that is calculated is desirably one that is freefrom drift.

[0128]FIG. 4 is a flow diagram that describes one method of providingoffset parameters in a timecode. The method described below is, in somerespects, an embellishment of step 304. Step 400 provides multiple mediasamples. Step 402 provides a timecode having an offset parameter. Step404 gets a first media sample. Step 406 then incorporates a timecodewith an offset parameter into the media sample. Step 408 determineswhether a pre-determined condition has occurred. Any suitable conditioncan be used. In the above example, the condition was associated withwhether the seconds counter in the timecode turned over. In someexamples below, a pre-determined condition occurs if a determined numberof frames are dropped.

[0129] If step 408 determines that the condition has not occurred, thenstep 410 gets the next timecode (which may or may not include the offsetparameter) and returns to step 404. If, on the other hand, step 408determines that the condition has occurred, step 412 adjusts the offsetparameter and returns to step 410 to get the next timecode. Adjustingthe offset parameter can take place in any suitable way, given thespecific type of media that is being processed. In the above example,the offset parameter was adjusted by incrementing it a predeterminedamount. It is possible, in some situations, for the offset parameter tobe decremented. An example of this is given below.

[0130] Once the offset parameter has been adjusted, step 410 gets thenext timecode (which preferably includes the adjusted offset parameter)and returns to step 404.

[0131] In this manner, multiple media samples can be provided withoffset parameters which can be used to ascertain a time measureassociated with the sample. This time measure can desirably be a moreaccurate time measure than is associated with a timecode that, becauseof its association with a non-integer frame rate, necessarily includessome drift.

Example 2

[0132] The following example is given in the context of NTSC(approximately 29.97 frames per second) with SMPTE Drop Counting.

[0133] U.S. NTSC color video runs at approximately 29.97 frames/sec. Ifsynchronized with program material at 30 frames/sec, there is an extra0.03 frames every second, adding up to 3.6 seconds every hour or 108extra frames. Drop Frame timecode was developed to reduce this driftthat can cause synchronization problems. It does this by “dropping”certain specific timecodes in the sequence of timecodes. The adjustmentmethod used in SMPTE Drop Frame timecode was to drop two timecode valueseach minute except for every tenth minute (minutes 00, 10, 20, 30, 40,50). An example would be that 01:22:59:29 advances directly to01:23:00:02, rather then first advancing to 01:23:00:00, then01:23:00:01, and then 01:23:00:02. Codes 01:23:00:00 and 01:23:00:01 aredropped. This allows the timecode to run much closer to true time oversignificant periods.

[0134] A SMPTE NTSC drop-frame timecode can be represented in thetimecode data structure fields of CountComp, Hours, Minutes, Seconds,and Frames without substantial alteration. The other parameters of thetimecode should be specified as:

[0135] MaxDays=1;

[0136] CountComp=‘01’ (SMPTE drop-frame counting);

[0137] BaseUPF=1001;

[0138] BaseUPS=30000 (for frame-based timestamps), or 60000(field-based);

[0139] BaseFPF=1 (for frame-based timestamps), or 2 (field-based);

[0140] Fields=0 (for frame-based timestamps), or 0 or 1 (field-based);

[0141] The Offset parameter should then be set to the value of Drift ascomputed by the C++ code above (i.e. initially set to zero, thenincremented by 30 (frame-base) or 60 (field based) each time the valueof Seconds increments, unless this occurs along with two frame countdrops at temporal locations as indicated in the pseudo-C code above, inwhich case it should be decremented by 1972 (frame-based) or 3944(field-based) instead).

[0142] Note that the SMPTE timecode can then later be extracted directlyfrom the CountComp, Hours, Minutes, Seconds, and Frames parameters, asits parameter values have been preserved without alteration.

[0143] Essentially then, determining the offset parameter in drop framecounting operates in much the same way as the example above, except thatthe offset parameter is adjusted to compensate for the dropped values.Specifically, every time the seconds counter rolls over to the initialcount (i.e. from 29 to 0), the offset is incremented by 30. There is,however, a specific rule for adjusting the offset parameter when thedropped values occur. Specifically, when the frame counts are skipped,instead of incrementing the offset by 30, it is decremented by apredetermined value which, in this case is 1972.

[0144] The value that is used for decrementing the offset parameters isdetermined as follows. When the seconds counter rolls over, you wouldnormally add 30. You have to compensate, however, for the fact that twoframe counts have been dropped. This constitutes a negative offset of{fraction (2002/30,000)}. Thus, 2002−30=1972—the predetermined value.

Example 3

[0145] The following example is given in the context of PAL (50 fieldsper second) with SMPTE Timecode. A SMPTE PAL timecode can be representedin the timecode data structure fields of CountComp, Hours, Minutes,Seconds, and Frames without substantial alteration. The other parametersof the timecode should be specified as:

[0146] MaxDays=1;

[0147] CountComp=‘00’; (no counting compensation)

[0148] BaseUPF=1;

[0149] BaseUPS=25 (for frame-based timestamps), or 50 (field-based);

[0150] BaseFPF=1 (for frame-based timestamps), or 2 (field-based);

[0151] Fields=0 (for frame-based timestamps), or 0 or 1 (field-based);

[0152] The Offset parameter should then be set to the value of Drift ascomputed by the process described by the C++ code above (always zero inthis case).

[0153] Note that the SMPTE timecode can then later be extracted directlyfrom the CountComp, Hours, Minutes, Seconds, and Frames parameters, asits parameter values have been preserved without alteration.

Example 4

[0154] When film is broadcast in the US, the film material itself istypically shot at 24 frames per second. The broadcast, however,typically takes place at {fraction (30,000/1001)} frames per second.Accordingly, there is a known practice called “2:3 pull-down” (alsoreferred to as “3:2 pull-down”), that adjusts the content byperiodically repeating individual fields of video. One goal of thisembodiment is to provide a way of time-stamping video that is shot at 24frames-per-second, such that when it is broadcast at {fraction(30,000/1001)} frames-per-second, a properly configured receiver canascertain the original association of the individual fields thatcomprise each frame of video to their original film frames and canascertain the approximate relative timing of those individual fields.

[0155] Consider, for example, FIG. 5 and the explanation that follows. Avideo frame can, for example, have two fields—one designated F1, theother designated F2. When the video frame is shot at 24 frames persecond, each of these fields is shot at the same time (because the framethat contains the two fields was shot at the same time). That is, ifthere were a timecode associated with F1 and F2 in the original video asshot, it should have the same timecode value.

[0156] The 2:3 pull-down process, however, repeats these fields in apredetermined manner when they are broadcast, and broadcasts the fieldsat different times. For example, field F1 is typically broadcast at time1, followed by field F2 at a different time 2, followed by field F1 atyet a different time 3. When the individual fields of a common frame arerepeated, bear in mind that they were actually sampled at the same time,but are being broadcast at a different time.

[0157] A timecode for each field of a 24 picture-per-second film whichhas been stretched by a factor of {fraction (1001/1000)} and convertedusing “2:3 pull-down” for use in NTSC video can be generated toindicate, via the offset parameter, the stretched timing andprogressive-sampling nature of the pictures that underlies the convertedinterlaced timing for NTSC field-oriented broadcast.

[0158] Film material shot at 24 pictures per second is normallyconverted to NTSC video by scanning each picture to create two fields ofalternating lines and, in every sequence of four pictures, repeating thetransmission of the first of every second and fourth picture aftersending the first and second fields of the picture, thus convertingevery four film-frame 24 frame per second pictures to ten fields of{fraction (30,000/1001)} frame per second video. This slows down theoverall timing by a factor of {fraction (1001/1000)} and allows the filmto be displayed as fields of interlaced video. However, it is useful tobe able to recover the underlying non-interlaced pictures by identifyingwhich fields actually belong together in their sampled timing.

[0159] What should ideally occur is that an indication should be madethat a particular field was sampled at exactly the same time as itsother associated fields. In accordance with this described embodiment,there is a way that one can show the actual time on each field of videowhen field repetition occurs in broadcasting film. This is done by usinga field counter and the offset parameter described above. Before,however, a specific discussion of how this can be done, consider thefollowing:

[0160] The human eye can perceive flicker depending on the brightness ofthe display if the display is refreshed at a rate less than about 60times/sec. If the flicker rate of what is being displayed to you is veryhigh, your eye won't see it.

[0161] There is an interesting tradeoff between trying to representmotion and trying to get rid of flicker. In the early days oftelevision, it was determined that the display had to be repainted anumber of times to show motion. To avoid having to repaint the wholedisplay to show motion, the concept of an interleaved display wasdeveloped. This concept involves displaying half of the lines of videoat one time, and then {fraction (1/60)}th of a second later displayingthe other half of the lines. By doing this, a viewer perceives motionnormally, and you can eliminate the flicker.

[0162] Using this approach, however, you are only getting 30 actual fullpictures in one second—or, to be more precise, you are getting 60 halfpictures in one second. So, if you look at what is being shown on thedisplay vertically, if you count 0 being the top line, 1 the next lineand so on, what you will see is lines 0, 2, 4, 6, 8, etc. at time 1, andthen {fraction (1/60)}^(th) of a second later, you will see lines 1, 3,5, 7, 9, etc.

[0163] A frame of video comprises the entire set of lines on a display.Afield of video comprises either the set of even or odd numbered lineson the display, as noted above. In accordance with one embodiment, atimecode representation is provided that gives the ability to have atime tag on each particular field instead of just on a frame. This timetag can then be processed to provide the actual time that an individualfield was sampled, notwithstanding the fact that it is broadcast at atime that is different from its other commonly-sampled fields. This isan improvement over SMPTE techniques which provide for timecoderepresentations only on frames.

[0164] As an example of how individual fields can be time-stamped,consider FIG. 6 which shows an exemplary timecode counter 600. In thisparticular timecode counter, the illustrated components include a framecounter 602, a seconds counter 604, an offset counter 606, and a fieldcounter 608. Other standard components that might be found in a SMPTEtimecode counter (i.e. hours, minutes) have been eliminated for purposesof this discussion.

[0165] In this present example, there are two fields per frame of video.Each field is associated with either the even or odd lines in the video.Accordingly, field counter 608 counts each field by counting between 0and 1. This is similar in some respects to the way that the framecounter counts frames. Specifically, the field counter 608 is configuredto handle the field counting as a sub-unit of a frame.

[0166] Thus, if one wants to build a field-based timecode, in thisexample, there are two fields in a frame. This means that the number ofunits per second doubles—because instead of each frame being {fraction(1001/30,000)} second, one needs to say that each field is half thatamount of time, i.e. {fraction (1001/60,000)} second. Accordingly then,there are two fields in a frame where the second field occurs {fraction(1001/60,000)} sec after the first field of the frame.

[0167] This being the case, consider again FIG. 6. For each time thatframe counter 602 increments, field counter 608 increments twice. Thatis, after “0:0:0:0” (i.e. the first row), the field counter incrementsso that the timecode value is “1:0:0:0”. Accordingly, to compute thetrue time associated with a field, instead of computing the time usingonly the frame counter as above, the true time is given by the followingequation:

t=s+((field_counter+FPF*frame_counter)UPField+offset)/UPS

[0168] This equation can be used, for example, to program a receiverthat receives the video at {fraction (30,000/1001)} frames per second,yet desires to extract the original timing information associated withthe 24 frames-per-second film. This may involve a minor stretching ofthe time durations by a factor of {fraction (1001/1000)}, but will notdistort the regularly-spaced characteristics of the fields that aretransmitted—as does operation without the offset factor.

[0169] This approach recognizes that there is an integer number offields in a frame, and, instead of just a frame counter, there is anadditional field counter that is provided that enables each field tocarry its own timestamp which provides information that can be used tocalculate the true time associated with the field.

[0170] 23.976 Frames Per Second in NTSC with SMPTE Non-Drop Counting

[0171] The underlying picture sampling timing as stretched to {fraction(24,000/1001)} (approximately 23.976) frames per second, can beindicated as underlying a SMPTE non-drop timecode, as per the following:

[0172] MaxDays=1;

[0173] CountComp=‘00’; (no counting compensation)

[0174] BaseUPF=2002;

[0175] BaseUPS=120000;

[0176] BaseFPF=2;

[0177] Fields=0 or 1 (field-based);

[0178] First a five-element array is defined as follows: Z[5]{0, −2002,1001, −1001, −3003}. Next, the Offset is set to Drift+Z[0] for the firsttransmitted field, to Drift+Z[1] for the second, Drift+Z[2] for thethird (which is the first field of the second transmitted picture),Drift+Z[3] for the fourth, Drift+Z[4] for the fifth, Drift+Z[5] for thesixth, then Drift+Z[0] for the seventh, Drift+Z[1] for the eighth, etc.,where Drift is computed as described in the C++ code above for eachfield (initially zero, then incremented by 120 for each time that theSeconds parameter increments).

[0179] As an example of the above approach for representing anunderlying picture sampling timing, consider FIG. 7 which shows agraphical representation of video that was shot at 24 frames per second,but broadcast at {fraction (30,000/1001)} frames per second using 2:3pull down. The y-axis represents the vertical axis of the individualframes and is divided into a “top field” that represents a first field,and a “bottom field” that represents a second field. The x-axis is thetime axis and represents the time when the individual fields from eachframe are received in their {fraction (30,000/1001)} frame-per-secondpulled down configuration.

[0180] In this example, there are four frames of video designated framesA, B, C, and D. To get to the depicted graphical representation, oneframe of film is taken (e.g. frame A) and the lines within the “topfield” are transmitted. This field is indicated at 700. Then the linesthat were not transmitted (i.e. the “bottom field” 702) are thentransmitted. The next frame—frame B—is then processed and three fieldsare transmitted by transmitting the top field 704, then the bottom field706, and then repeating the top field 704. Next, the bottom field 708for frame C is transmitted, followed by the top field 710 for frame C.And finally, three fields for frame D are transmitted by transmittingbottom field 712, then top field 714, and then repeating bottom field712.

[0181] This process of alternating two-fields of a frame—three fields ofanother frame, is then repeated. All of the lines in the fieldscomprising a single frame were sampled at the same time. Yet, however,these lines or fields are transmitted at separate times. The result ofthis is that every other 24 frame per second frame is going to lastlonger than it normally would if, for example, you were watching themovie as shot, and the remaining frames will be displayed for somewhatless time than the original timing would indicate—producing, on average,approximately the correct overall duration of the program.

[0182] Specifically, what this process provides is, for four frame timesat 24 frames per second (which is 4 intervals of {fraction (1/24)} of asecond=0.166666), you now have ten fields of video which is10*({fraction (1001/60,000)})={fraction (10,010/60,000)}=0.16683333.These two values are approximately equal, and differing only by a factorof {fraction (1001/1000)}.

[0183] There is, however, a problem here. Specifically, if you receivethe video in the 2:3 pull down form, and you want to try to put it backtogether in the original time that it was sampled, prior to theembodiment described above, you could not do it. That is, instead oftrying to see the actual broadcast times of the sample (where each fieldhas a different timestamp), you wish to see the original timing of thesample (where, for example, individual fields of the same frame have thesame timestamp).

[0184] Thus, ideally, what you want and, in fact, what theabove-described embodiment provides is a timestamp on each one of thefields that has the true sample time of that field, or can be used toascertain the true sample time of the field—even though the fields weretransmitted at different times.

[0185] This embodiment provides a way of putting timecodes on the fieldsthat, instead of indicating a set of time intervals that isfundamentally inaccurate (i.e. the set of time intervals that coincidewith the broadcast time of the individual fields of video), each fieldrepresents the time associated with the original film frame—slightlystretched by a factor of {fraction (1001/1000)}. So then, a videoreceiver can know how it can put the data back together into itsoriginal form when things are sampled at the correct times relative toeach other.

[0186] As an example of how this can be done, consider the equationbelow, FIG. 6, and the example below:

t=s+((field_counter+FPF*frame_counter)UPField+offset)/UPS

[0187] In this case, UPField=2002 (because you need to be able to showtimes that are half way between the times that you would otherwisecalculate), UPS=120,000 (because of the interaction between the 24frames/sec and the 30 frames/second), and FPF=2.

[0188] For the first field, s=0, field_counter=0, frame_counter=0 andoffset=Z[0] or 0. Accordingly, the time t=0 which is what one wouldexpect. For the second field (which is the second field of the firstfilm frame), one would expect time t=0 as well, since that field wascaptured at the same time as the first field. In this case, s=0,field_counter=1, frame_counter=0, and offset=z[l] or −2002. Using thesenumbers in the above equation, t=0 +((1+2*0)*2002-2002)/120,000=0 asexpected. For the third field (which is the first field of the secondfilm frame), one would expect time t={fraction (1001/24,000)},indicating that it is in the next film frame. In this case, s=0,field_counter=0, frame_counter=1, and offset=z[2] or 1001. Using thesenumbers in the above equation, t=0+((0+2*1)*2002+1001)/120,000={fraction(3003/120,000)}={fraction (1001/24,000)} as expected.

[0189] 23.976 Frames per Second in NTSC with SMPTE Non-Drop Counting

[0190] The underlying picture sampling timing as stretched to {fraction(24,000/1001)} (approximately 23.976) frames per second can be indicatedas underlying a SMPTE Drop-Frame timecode, as per the following:

[0191] MaxDays=1;

[0192] CountComp=‘01’; (SMPTE drop-frame counting compensation)

[0193] BaseUPF=2002;

[0194] BaseUPS=120000;

[0195] BaseFPF=2;

[0196] Fields=0 or 1 (field-based);

[0197] Define the five-element array Z[5]={0, −2002, 1001, −1001,−3003}. Set Offset to Drift +Z[0] for the first transmitted field, toDrift+Z[1] for the second, Drift+Z[2] for the third (which is the firstfield of the second transmitted frame), Drift+Z[3] for the fourth,Drift+Z[4] for the fifth, Drift+Z[5] for the sixth, then Drift+Z[0] forthe seventh, Drift+Z[l] for the eighth, etc., where Drift is computed asshown in the C++ code above (i.e. initially zero, then incremented by120 for each time that the Seconds parameter increments, unless thisoccurs along with two frame count drops at temporal locations, in whichcase Drift is decremented by 7888 instead).

[0198] Effectively, both of the embodiments described above provide away for time-stamping individual fields such that the time stamps offrames that have been stretched into a different format—here {fraction(30,000/1001)} frames per second—can be processed to provide theoriginal association of those fields with each other into frames withproper relative sampling times, with a minor adjustment of the originaltiming by a factor of {fraction (1001/1000)}. In accordance with theseembodiments, fields that comprise a common frame will evaluate to thesame sampled time value, rather than a time value associated with itsactual broadcast time.

[0199] Design Improvement Relative to Other Timecodes

[0200] The above-described embodiments have characteristics that canclearly improve other timecodes. Specific examples of this are givenbelow.

[0201] Improvement Relative to SMPTE Timecode

[0202] A timecode widely used in the video production industry is knownas SMPTE timecode, and is normally represented in manner equivalent tothat shown in Table 3. Its use is so common that interworking with SMPTEtimecode is essential in the video production environment. TABLE 3 SMPTETimecode Parameter Name Parameter Type Size (bits) Range of ValuesDropFlag bool 1 0 or 1 NTSC vs PAL bool 1 0 or 1 Hours int 5 or more 0to 23 Minutes int 6 or more 0 to 59 Seconds int 6 or more 0 to 59 Framesint 5 or more 0 to 29/0 to 24

[0203] If NTSCvsPAL is 0, BaseUPF=1001 and BaseUPS=30,000; otherwise,BaseUPF=1 and BaseUPS=25. BaseFPF is implicitly 1, although the SMPTEtimecode is actually typically used with interlaced-scan video (whichhas two interlaced fields per frame).

[0204] SMPTE timecode has no direct 1:1 correspondence with true time,so a conversion between SMPTE timecode and true time cannot be trulyexpressed. The DropFlag flag indicates a choice between no countingcompensation and the SMPTE drop-frame counting compensation as describedabove.

[0205] The disadvantages of this timecode are enumerated as follows:

[0206] It does not accurately relate to true “wall clock” time—insteadit starts at a time that is not precisely known (only known to a frameincrement in temporal resolution) and accumulates a “drift” relative to“wall clock” time as it progresses (a drift which is reduced but noteliminated by the use of “drop frame” counting).

[0207] It does not specify single-field time increments for interlacedvideo, despite the fact that it is primarily used in interlaced videoenvironments.

[0208] If a SMPTE timecode is converted directly to a “wall clock” timewhich does not have all of the Hours, Minutes, Seconds, Frames, andDropFlag parameters, the time measurement cannot be easily andunambiguously converted back to a SMPTE timecode.

[0209] Since its equivalent of BaseUPF and BaseUPS allow only a coupleof fixed values, it cannot represent some frame rates precisely.

[0210] It includes no representation of a field count parameter, despitebeing primarily applied to video with two interlaced fields per frame(and its BaseUPS does not have sufficient temporal accuracy to preciselyrepresent the timing of the two interlaced fields of each frame).

[0211] In contrast, the design described above can carry a SMPTEtimecode without altering it, while also being able to represent aprecise relationship between the time of a sample and a true “wallclock” time. Its compatibility with SMPTE time makes it capable of wideuse in the video production industry, but it also corrects the temporalambiguity resulting from use of SMPTE timecodes.

[0212] Improvement Relative to MPEG-2:2000 N3438 Draft Amend. 1

[0213] MPEG-2:2000 N3438 Draft Amendment 1 [InternationalStandardization Organization and International ElectrotechnicalCommission Joint Technical Committee Number 1 Working Group Number 11Moving Picture Experts Group document N3438 Video Elementary StreamSupplemental Information: June 2000] contains a timecode format that isequivalent to that shown in Table 4. TABLE 4 MPEG-2: 2000 N3438 TimecodeDesign Parameter Name Parameter Type Size (bits) Range of Values Discontbool 1 0 or 1 Hours int 5 or more 0 to 23 Minutes int 6 or more 0 to 59Seconds int 6 or more 0 to 59 Offset int 7 or more ≧0

[0214] The equivalent timestamp is calculated as follows:

t=(60•(60•Hours+Minutes)+Seconds+Offset/27,000,000

[0215] The disadvantages associated with this timecode are as follows:

[0216] It has no concept of frame or field counters, only absolute time.

[0217] It has no concept of a time increment associated with aninter-frame or inter-field interval.

[0218] As it has no frame counter, it cannot represent drop-framecounting of frames.

[0219] It cannot directly carry a SMPTE timecode.

[0220] If a SMPTE timecode is converted to a timestamp in this format,it cannot be readily converted back to a SMPTE timecode.

[0221] Since its equivalent of BaseUPS (the constant 27,000,000) has afixed value, it cannot represent some frame rates precisely.

[0222] The above-described embodiments can improve upon thesedisadvantages as will be apparent to those of skill in the art.

[0223] Improvement Relative to ITU-TH.263+Frame Times

[0224] In H.263+[International TelecommunicationsUnion—Telecommunications Standardization Sector, ITU-T RecommendationH.263 version 2:1998), time is represented in manner equivalent to thatshown in Table 5. TABLE 5 H.263 + Time Representation Parameter NameParameter Type Size (bits) Range of Values ClockBaseAdd1 bool 1 0 or 1ClockDivisor int 7 1 to 127 Frames int 8 or 10 ≧0

[0225] The equivalent timestamp is calculated as follows:

t=Frames•(ClockDivisor•(1000+ClockBaseAdd1))/1,800,000

[0226] The disadvantages associated with this timecode are as follows:

[0227] It cannot directly carry a SMPTE timecode.

[0228] If a SMPTE timecode is converted to a timestamp in this format,it cannot be readily converted back to a SMPTE timecode.

[0229] Since its equivalent of BaseUPS (the constant 1,800,000) has afixed value, it cannot represent some frame rates precisely.

[0230] It has no field counter, and thus cannot indicate timestamps fora division of frames into fields.

[0231] As will be appreciated by those of skill in the art, theinventive approaches described above can improve upon one or more ofthese disadvantages.

[0232] Improvement Relative to MPEG-4 Visual VOP Time

[0233] The MPEG-4 Visual standard [International Standards Organizationand International Electrotechnical Commission, International Standard14496-2:1999] represents timecode in a manner equivalent to that shownin Table 6. TABLE 6 MPEG-4 Visual VOP Time Parameter Name Parameter TypeSize (bits) Range of Values BaseUPS int 16 ≧0 Hours int 5 or more 0 to23 Minutes int 6 or more 0 to 59 Seconds int 6 or more 0 to 59 AddSecint 1 or more ≧0 Offset int 1 to 16 0 to BaseUPS-1 FixedIncrement int 1to 16 0 to BaseUPS-1 FixedRateFlag bool 1 0 or 1

[0234] The equivalent timestamp can be calculated as follows:

t=60•(60•Hours+Minutes)+Seconds+AddSec+Offset/BaseUPS

[0235] When FixedRateFlag is 1, the time difference between thetimestamps of every adjacent pair of samples must be equal toFixedIncrement.

[0236] The disadvantages associated with this timecode are as follows:

[0237] When FixedRateFlag is 0, it has no concept of a frame counter,only an absolute time.

[0238] When FixedRateFlag is 1, it has no ability to indicate skippedsamples and has no flexibility on the amount of time indicated betweenpairs of samples.

[0239] Since it does not use a BaseUPF to multiply a frame count, thenumber of bits required to represent the location of a sample timestampwithin a one second interval is larger than would be necessary if usinga BaseUPF (in contrast with the H.263+ design, for example). If aBaseUPF were used instead, then just having a frame or field counterusing a small number of bits which increments by one with each samplewould be all that would be necessary to represent frame time increments,and a simple increment by two could indicate a skipped frame sample.

[0240] It has no concept of a time increment associated with aninterframe interval.

[0241] As it has no frame counter, it cannot represent drop-framecounting of frames.

[0242] It cannot directly carry a SMPTE timecode.

[0243] If a SMPTE timecode is converted to a timestamp in this format,it cannot be readily converted back to a SMPTE timecode.

[0244] The above-described inventive approaches can improve upon one ormore of these disadvantages, as will be apparent to those of skill inthe art.

[0245] Improvement Relative to Timecode Object (TCO) Draft

[0246] A preliminary design has been circulated in the video productionindustry of a “timecode object” for a draft specification of a timecodefor use in television, audio, and film production [Brooks Harris,Proposed SMPTE Standard S22.TCO×I-1999 Nov. 18, 1999]. The designcirculated is in draft form and appears to contain some errors, but itappears essentially equivalent to that shown in Table 7. TABLE 7Timecode Object (TCO) Draft Parameter Name Parameter Type Size (bits)Range of Values NTSC vs PAL bool  1 0 or 1 CountComp enum  2 3 enumvalues SampleRate enum  5 16 enum values Frames int  5 ≧0 Field int  1 0or 1 NTPtime int 64 ≧0

[0247] It contains a Frames counter, a Field indication, and arepresentation of wall clock time. It uses a specification of a samplingrate by selecting from among a number of specific sampling rates. Itcontains an indicator for whether to use SMPTE “drop frame” counting ora specific counting method known as a “1000 day compensated count” whichreduces drift error by using a specific counting pattern in a 1000 dayperiod. The “1000 day compensated count” is a specific counting methodthat does not use a calculation of drift accumulation (instead it uses afixed counting pattern similar to but more complex than the “drop frame”method of SMPTE 12M timecode). It contains some specific provisions fordealing with leap days, leap seconds, and time zones. It does notcontain a method for offsetting a frame-based timecode to reference itto a true wall clock time based on a general timebase in units persecond. It does contain “wall clock” date and time parameters, but theseare represented in network time protocol (NTP) [Internet EngineeringTask Force Request For Comments number 1305] units (not in units persecond having a customizable relationship with the sampling rate). TheNTP units of time use fixed measurement units of approximately 2⁻³²seconds (i.e., its equivalent of BaseUPS has a fixed value of 2³², anumber which is not an integer multiple of conventional timebasesampling units such as 30,000 or 25) and thus these representations usea fixed precision that is not compatible with common sampling rates,contain rounding error, and are not based on the sampling timing. Itcannot always carry a SMPTE 12M timecode without alteration, due to thedrift between the SMPTE 12M representation of time and the timerepresented in this timecode's NTP time parameter. Disadvantages of thistimecode object design include:

[0248] It only specifies sampling rates using an enumeration of selectedspecific sampling rates, not a general representation of time using aBaseUPS number of units per second and a BaseUPF number of units perframe.

[0249] It cannot represent the true time of a sample without roundingerror using a customized BaseUPS number of units per second (true timeis represented only in NTP units having a fixed number of increments persecond).

[0250] Conversion between its representation of time (using NTP) and theconventional SMPTE 12M timecode is not well defined, as it does notcontain a representation that directly corresponds to the same values asthe Hours, Minutes, and Seconds parameters found in the SMPTE 12Mtimecode (since its NTP time is not directly based on the values of theHours, Minutes and Seconds parameters that would be found in theconventional SMPTE 12M timecode due to drift between conventional SMPTE12M time and NTP time).

[0251] It does not contain a method of counting compensation based on adirect computation of accumulated drift. Instead it defines a new andcomplex special method of counting to reduce drift using a specific“1000 day count”.

[0252] The inventive approaches described above improve upon one or moreof these disadvantages as will be apparent to those of skill in the art.

[0253] Counting Compensation

[0254] In accordance with another embodiment, various methods areprovided for eliminating drift over time. A first embodiment is referredto as “top drop” counting, and a second embodiment is referred to as“bottom drop” counting.

[0255] Top Drop Counting

[0256] In accordance with one described embodiment, a method is providedthat compensates for drift between a media sample frame count timerepresentation, and true “wall clock” time by computing the driftbetween the time represented by the hours, minutes, seconds, and framecount and the true “wall clock” time of the sample, and skipping overthe maximum frame number on occasion to prevent excessive drift. Forexample, the maximum frame number may be skipped whenever theaccumulated drift exceeds the time represented by a frame countincrement.

[0257]FIG. 8 is a flow diagram that describes steps in a method inaccordance with one top drop counting method. The method can beimplemented in any suitable hardware, software, firmware, or combinationthereof. In the illustrated example, the method is implemented insoftware.

[0258] Step 800 determines a time value associated with a frame countincrement. Recall from the examples above that when media samples aretimecoded, each frame of a media sample has an increment of timeassociated with it. For example, each frame count increment mightconstitute an increment of {fraction (1/24)} second. This stepdetermines the time value associated with that frame count increment.Step 802 computes an accumulated drift between a timecode associatedwith a media sample, and the true “wall clock” time or true sample timeassociated with that media sample. Step 804 skips a maximum frame numberwhen the accumulated drift exceeds the time represented by a frame countincrement.

[0259] As an example, consider the following: In order to eliminatedrift over time, the Frames parameter (as described above) willsometimes count up from 0 to MaxFPS-1 and will sometimes count up onlyfrom 0 to MaxFPS-2 (dropping the top count). (MaxFPS is defined above).If the basic frame rate is 7.3 frames per second, then sometimes therewill be seven frames counted in a second and sometimes eight (so theFrames count will sometimes count from 0 up to 6 and sometimes from 0 upto 7).

[0260] Bottom Drop Counting

[0261] In accordance with one described embodiment, a method ofcompensating for drift between a media sample frame count timerepresentation and true “wall clock” time is provided by computing thedrift between the time represented by the hours, minutes, seconds, andframe count and the true “wall clock” time of the sample, and skippingover the minimum frame number on occasion to prevent excessive drift.For example, the minimum frame number may be skipped whenever theaccumulated drift exceeds the time represented by a frame countincrement.

[0262]FIG. 9 is a flow diagram that describes steps in a method inaccordance with one bottom drop counting method. The method can beimplemented in any suitable hardware, software, firmware, or combinationthereof. In the illustrated example, the method is implemented insoftware.

[0263] Step 900 determines a time value associated with a frame countincrement. This step is essentially the same as step 800 above. Step 902computes an accumulated drift between a timecode associated with a mediasample, and the true “wall clock” time or true sample time associatedwith that media sample. This step is essentially the same as step 802above. Step 904 skips a minimum frame number when the accumulated driftexceeds the time represented by a frame count increment.

[0264] As an example, consider the following: In order to eliminatedrift over time, the Frames parameter will sometimes count up from 0 toMaxFPS-1 and sometimes will sometimes count up only from 1 to MaxFPS-1(dropping the bottom count). This counting method is similar to that ofthe top-dropping method above, but in this case, the Frames parametervalue of 0 that is skipped rather than the highest value of the Framesparameter.

[0265] Conclusion

[0266] Various embodiments described above provide a means by which anaccurate reference to “true time” can be provided in a timecodeassociated with a media sample. The embodiments can be compatible withexisting timecode paradigms by containing the fields of these existingtimecode designs without alteration, although possibly adding one ormore additional parameters to enhance the capability of the design.Additionally, improvements are achieved in the form of new countingcompensation methods.

[0267] Although the invention has been described in language specific tostructural features and/or methodological steps, it is to be understoodthat the invention defined in the appended claims is not necessarilylimited to the specific features or steps described. Rather, thespecific features and steps are disclosed as preferred forms ofimplementing the claimed invention.

1. A data structure for use in timecode representation comprising: oneor more time measure parameters associated with a media sample and whichcan be used to specify a nominal time associated with the media sample;and an offset parameter to specify a difference between the timespecified by the one or more time measure parameters and a representedtime associated with the media sample.
 2. The data structure of claim 1,wherein the one or more time measure parameters are defined in terms ofSMPTE timecode parameters.
 3. The data structure of claim 1, wherein theone or more time measure parameters comprise a SMPTE NTSC non-drop ordrop-frame timecode.
 4. The data structure of claim 1, wherein the oneor more time measure parameters comprise the following parameters:hours, minutes, seconds and frames; or equivalently, seconds and frames.5. The data structure of claim 1, wherein the one or more time measureparameters comprise the following parameters: hours, minutes, secondsand fields; or equivalently, seconds and fields.
 6. The data structureof claim 1, wherein the one or more time measure parameters comprise thefollowing parameters: hours, minutes, seconds, frames, and fields; orequivalently, seconds, frames, and fields.
 7. The data structure ofclaim 1, wherein the one or more time measure parameters comprise atleast a field parameter that is associated with one or more fieldscomprising a media sample frame.
 8. The data structure of claim 1further comprising a discontinuity parameter configured to specifywhether there is a discontinuity at a boundary between a specific mediasample and another specific adjacent sample.
 9. A data structure for usein timecode representation comprising: one or more time measureparameters associated with a media sample and which can be used tospecify a time associated with the media sample; and an offset parameterdefined by a units-per-second denominator factor to be used to referencethe one or more time measure parameters to a represented time.
 10. Thedata structure of claim 9, wherein the offset parameter can be used toreference the one or more time measure parameters to the true time formultiple different sampling rates.
 11. The data structure of claim 10,wherein the sampling rates comprise rates selected from a groupcomprising: {fraction (24,000/1001)} frames per second, 24 frames persecond, {fraction (30,000/1001)} frames per second, 30 frames persecond, {fraction (60,000/1001)} frames per second, 60 frames persecond, and 25 frames per second.
 12. The data structure of claim 9,wherein the units-per-second denominator factor can have a generalinteger value.
 13. The data structure of claim 9, wherein theunits-per-second denominator factor can have a value of a fixed integerconstant divided by a general integer value, in which the integerconstant is an integer multiple of 30,000.
 14. The data structure ofclaim 9, wherein the units-per-second denominator factor can have one ormore values, at least one of which is an integer multiple of 30,000. 15.The data structure of claim 9, wherein the units-per-second denominatorfactor can have only one value, said value being an integer multiple of30,000.
 16. The data structure of claim 9 further comprising a framenumber parameter which indicates a frame number, and a units-per-framenumerator factor that can have a general integer value.
 17. The datastructure of claim 9 further comprising a frame number parameter whichindicates a frame number, and a units-per-frame numerator factor thatcan have one or more values, at least one of which is an integermultiple of
 1001. 18. The data structure of claim 9 further comprising afield number parameter which indicates a field number, and afields-per-frame parameter which specifies a number of fields per frame.19. The data structure of claim 18, wherein the number of fields perframe can have a general integer value.
 20. The data structure of claim18, wherein the number of fields per frame can have one or more values,at least one of which is
 2. 21. The data structure of claim 18, whereinthe number of fields per frame can have only one value equal to
 2. 22.The data structure of claim 18 further comprising a units-per-fieldnumerator factor that can have a general integer value.
 23. The datastructure of claim 18 further comprising a units-per-field numeratorfactor that can have one or more values, at least one of which is aninteger multiple of
 1001. 24. The data structure of claim 9 furthercomprising a parameter that indicates a timecode increment countingmethod comprising SMPTE timecode non-drop or drop frame counting.
 25. Adata structure for use in timecode representation comprising: one ormore time measure parameters associated with a media sample and whichcan be used to specify a time associated with the media sample; and anoffset parameter defined by a: units-per-second denominator factor to beused to reference the one or more time measure parameters to arepresented time, the units-per-second denominator factor being capableof having one or more values, at least one of which is an integermultiple of 30,000; and a units-per-frame numerator factor that can haveone or more values, at least one of which is an integer multiple of1001.
 26. A data structure for use in timebase representationcomprising: a first parameter associated with a number of basic units oftime in the timebase per second; second parameter associated with basicunits of time to be added for each field count increment; and thirdparameter associated with a number of fields defined for each frame. 27.The data structure of claim 26 further comprising a fourth parameterassociated with a method that can be used to compensate frame countingincrements to reduce or eliminate drifts over time between true time anda timecode timestamp.
 28. A method of providing a timecode comprising:providing multiple media samples; counting the media samples both withrespect to media sample frames and fields within media sample frames;and timecoding the multiple media samples with a timecode comprising:values associated with media sample frames, values associated withfields within media sample frames, and an offset that can be used toascertain a represented time associated with individual fields withinthe media sample frames.
 29. A method of providing a timecodecomprising: providing a plurality of media samples at a particular framerate, the media samples having associated timecodes; and offsettingdrift associated with the media samples by using an offset parameterthat specifies a difference between a time measure defined by theassociated timecodes and a represented time associated with the mediasamples.
 30. The method of claim 29, wherein the frame rate is not aninteger frame rate.
 31. One or more computer-readable media havingcomputer-readable instructions thereon which, when executed by acomputer, cause the computer to: provide a plurality of media samples ata particular non-integer frame rate, the media samples having associatedtimecodes; and offset drift associated with the media samples by usingan offset parameter that specifies a difference between a time measuredefined by the associated timecodes and a represented time associatedwith the media samples.
 32. A method of processing media samplescomprising: providing one or more media samples individual ones of whichhave a timecode; and calculating a represented time associated with oneor more of the media samples in accordance with the following equation:time=x+(frame count*UPF+offset)/UPS, where: x is a measure of timeassociated with the media sample and ascertained from the media sample'stimecode; “frame count” is a value associated with a frame number of themedia sample; “UPF” comprises a number of basic units of time to beadded for each field count increment; “offset” specifies a differencebetween the time represented by the timecode associated with the mediasample and a represented time; and “UPS” comprises a number of basicunits of time in a timebase per unit of time.
 33. The method of claim32, wherein “x” is associated with a number of seconds specified by thenumber of whole seconds represented in a SMPTE timecode, either as atotal number of seconds or as parameters representing hours, minutes,and seconds.
 34. The method of claim 32, wherein “offset” is selected asa function of a true frame rate of the media samples.
 35. The method ofclaim 34, wherein the true frame rate comprises a fractional number offrames per unit of time.
 36. The method of claim 35, wherein the unit oftime comprises seconds.
 37. A method of timecoding media samplescomprising: providing one or more media samples having a non-integerframe rate; timecoding the media samples with a timecode that containsan amount of drift due to the media samples having the non-integer framerate; and incorporating, in the timecode, an offset parameter that canbe used to calculate a reduced-drift time measure that is more accuratethan a time measure taken directly from the timecode.
 38. The method ofclaim 37, wherein said timecoding comprises including a fields parameterthat is associated with one or more fields comprising a media sampleframe.
 39. The method of claim 37, wherein the offset parameter can beused to calculate a drift-eliminated time measure.
 40. The method ofclaim 37 further comprising adjusting the offset parameter for at leastsome of the media samples.
 41. The method of claim 40, wherein saidadjusting comprises determining whether a pre-determined condition hasoccurred and responsive thereto, adjusting the offset parameter.
 42. Themethod of claim 41, wherein said pre-determined condition is associatedwith a seconds counter rolling over.
 43. The method of claim 41, whereinsaid pre-determined condition is associated with whether any frames aredropped.
 44. The method of claim 41, wherein said adjusting comprisesincrementing the offset parameter by a defined amount.
 45. The method ofclaim 41, wherein said adjusting comprises decrementing the offsetparameter by a defined amount.
 46. The method of claim 41, wherein saidadjusting comprises incrementing the offset parameter by a definedamount, and then at a different time decrementing the offset parameterby a different defined amount.
 47. The method of claim 37, wherein saidtimecode comprises a SMPTE non-drop counting timecode.
 48. The method ofclaim 37, wherein said timecode comprises a SMPTE drop countingtimecode.
 49. A method of processing media samples comprising: receivingmultiple media samples that have been timecoded with a timecode thatcontains an amount of drift due to the media samples having anon-integer frame rate, the timecode also containing an offset parameterthat can be used to calculate a reduced-drift time measure that is moreaccurate than a time measure taken directly from the timecode; andcalculating, using the offset parameter, a time measure that is moreaccurate than a time measure taken directly from the timecode.
 50. Themethod of claim 49, wherein the timecode comprises SMPTE timecodeparameters.
 51. A method of processing media samples comprising:providing multiple media samples at a frame rate in which there are anon-integer number of frames per unit of time associated with a mediasample timecode; providing an offset parameter that is associated withthe timecode and which describes a difference between the timerepresented by a timecode and the represented time; and using the offsetparameter, calculating a represented time associated with one or more ofthe media samples.
 52. The method of claim 51 further comprisingadjusting the offset parameter for at least one of the media samples.53. The method of claim 51 further comprising adjusting the offsetparameter for at least one of the media samples in accordance withoccurrence of a pre-determined condition
 54. A method of processingmedia samples comprising: providing multiple media samples; countingframes associated with the media samples to provide a frame count;counting fields associated with the media samples to provide a fieldcount; calculating an offset parameter associated with the media samplesand configured for use in calculating a represented time associated withthe media samples; and timestamping one or more of the media sampleswith a timestamp comprising a frame count, field count, and offsetparameter.
 55. The method of claim 54, wherein there are two fields perframe for each media sample.
 56. The method of claim 54, wherein saidtimestamping comprises timestamping the media samples with SMPTEtimecode parameters.
 57. The method of claim 54, wherein saidcalculating comprises adjusting an offset parameter value at least once.58. The method of claim 54, wherein said calculating comprises adjustingan offset parameter value at least once and in accordance with one ormore dropped frames.
 59. The method of claim 54, wherein saidcalculating comprises adjusting an offset parameter value at least onceand in accordance with a seconds counter rolling over.
 60. The method ofclaim 54, wherein the represented time can be calculated in accordancewith the following equation:t=x+((field_counter+FPF*frame_counter)UPField+offset)/UPS, where, x is ameasure of time associated with a media sample; “frame_counter” is theframe number associated with a media sample; “UPField” comprises anumber of basic units of time to be added for each field countincrement; “offset” specifies a difference between the time representedby a timecode associated with the media sample and the represented time;and “UPS” comprises the number of basic units of time in a timebase perunit of time.
 61. A method of processing media samples comprising:receiving multiple media samples individual ones of which have beentimestamped with a timestamp comprising a frame count, field count, andoffset parameter, the frame count being associated with a frame numberthat corresponds to a media sample, the field count being associatedwith a field number that corresponds to a particular frame, and theoffset parameter being associated with a represented time associatedwith a media sample; and calculating a represented time associated witha media sample using the offset parameter.
 62. The method of claim 61,wherein said calculating comprises calculating the represented time inaccordance with the following equation:t=x+((field_counter+FPF*frame_counter)UPField+offset)/UPS, where, x is ameasure of time associated with a media sample; “frame_counter” is theframe number associated with a media sample; “UPField” comprises anumber of basic units of time to be added for each field countincrement; “offset” specifies a difference between the time representedby a timecode associated with the media sample and the represented time;and “UPS” comprises the number of basic units of time in a timebase perunit of time.
 63. A method of processing media samples comprising:receiving media samples that were sampled using a first format, andbroadcast using a second format which constitutes separating fields fromframes of the first format, the media samples comprising individualframes each with multiple fields, the media samples further comprising atimecode value associated with each individual field, the timecodecomprising an offset parameter that specifies a difference between thetime represented by a timecode value associated with the media sampleand the represented time; and with the media samples in the secondformat, calculating a represented time associated with one or more ofthe fields in the first format.
 64. A counting compensation methodcomprising: determining a time value associated with a frame countincrement for a media sample; computing accumulated drift between atimecode associated with multiple media samples and true time; andoccasionally skipping a maximum frame number, while counting frames, toreduce the accumulated drift.
 65. A counting compensation method as inclaim 64, in which the maximum frame number is skipped when theaccumulated drift exceeds the time represented by a frame countincrement.
 66. A counting compensation method comprising: determining atime value associated with a frame count increment for a media sample;computing accumulated drift between a timecode associated with multiplemedia samples and true time; and occasionally skipping a minimum framenumber, while counting frames, to reduce the accumulated drift.
 67. Acounting compensation method as in claim 66, in which the minimum framenumber is skipped when the accumulated drift exceeds the timerepresented by the frame count increment.